BUNDES#EPUB LIK D EUTSQ>LAND ^ 

==E= 10/516569 



Recd 2 6 JUN 2003 

W!PO PCT 



Prioritatsbescheinigung iiber die Einreichung 
einer Patentanmeldung 



Aktenzeichen: 102 57 030.2 

Anmeldetag: 06. Dezember 2002 

Anmelder/lnhaber: Robert Bosch GmbH, Stuttgart/DE 

Bezeichnung: Verfahren und Vorrichtung fur einen fahrzeug- 

bezogenen Telematikdienst 

Prioritat: 10. Juni 2002 DE 102 25 788.4 

IPC: G 06 F 15/163 




Die angehefteten Stiicke sind eine richtige und genaue Wiedergabe der ur- 
spriinglichen Unterlagen dieser Patentanmeldung. 




MOnchen, den 16. Juni 2003 
Deutsches Patent- und Markenamt 
Der President 

Im Auftrag 



PRIORITY DOCUMENT 

SUBMITTED OR TRANSMITTED IN 
COMPLIANCE WITH 
RULE 17.1(a) OR (b) 




Dzierzon 



BEST AVAILABLE COPY 




04.12.02 Bee/Pz 

ROBERT BOSCH GMBH, 70442 Stuttgart 



Verfahren und Vorrichtung fur einen fahrzeugbezogenen Telematikdienst 
Stand der Technik 

Die Erfindung betriffl ein Verfahren und Vorrichtung fur einen f ahrzeugbezogenen 
Telematikdienst wie das Einwirken auf wenigstens eine Funktionalitat in einem Fahrzeug 
uber eine Luftschnittstelle, z.B. ein Mobilfunknetz, insbesondere in Verbindung mit der 
Ferndiagnose von Kraftfahrzeugen. 

Die zunehmende Vernetzung von Steuergeraten in heutigen Kraftfahrzeugen bietet inrmer 
bessere Einwirkungsmoglichkeiten auf Funktionalitaten im Kraftfahrzeug, z.B. bessere 
Diagnosemoglichkeiten imFehlerfall oder Moglichkeiten zur Fernbedienung von 
Funktionen und/oder Komponenten des Fahrzeugs. In diesem Zusammenhang bestehen 
Konzepte, mit Hilfe eines mobilfunkgestutzten Einwirkens zuverlassig und sicher auf die 
Funktionalitat im Fahrzeug uber beliebige Entfernungen hinweg zuzugreifen, 
beispielsweise iiber eine Ferndiagnose zuverlassige und qualitativ hochwertige 
Fehleranalysen durch ein Service-Center bzw. einen Ferndiagnose-Server, der eine 
entsprechende Diagnose-Datenbank umfasst, durchzufuhren. GemaB diesen Ansatzen 
werden im Fahrzeug integrierte Kommunikationssysteme wie beispielsweise 
Mobiltelefone und/oder GSM-gestiitzte Telematikendgerate genutzt, um eine 
Dateniibertragung zwischen den an ein Fahrzeugnetzwerk angeschlossenen Steuergeraten 
und/oder Komponenten und dem Server des Service-Centers durchzufuhren. Einen 
Vorschlag fiir ein derartiges System beschreibt die DE 100 26 754 AL Eine konkrete 
Realisierung hinsichtlich der tibertragungsinhalte zwischen Server und Endgerat sowie 
hinsichtlich der Ausgestaltung von Endgerat bzw. Server werden nicht angegeben. 



Vorteile der Erfindung 
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Durch die Aufteilung der Funktionen, z.B. Diagnosefunktionen, zwischen Endgerat und 
Server (Partitionieren von Teilfunktionen) wird eine erhebliche Ressourcenerspamis im 
Fahrzeugendgerat erreicht. Besonders vorteilhaft ist, dass zeitunkritische, 
fahrzeugspezifische Funktionen, mit denen das Einwirken auf die ausgewahlte 
Funktionalitat gesteuert wird, nicht im Fahrzeugendgerat, sondern im Server vorgehalten 
werden und von diesem iiber die Luftschnittstelle ubertragen werden. Dadurch wird 
vermieden, dass ein zusatzliches, speziell auf die Anwendung insbesondere hinsichtlich 
vomFahrzeugnetzwerk vorgegebenen zeitlichen Randbedingungen zugeschnittenes 
Applikations-ProtokoU fur die Luftschnittstelle notwendig ist, so dass auf ubliche 
Standard-Protokolle fur die Luftschnittstelle zuruckgegriffen werden kann. Erganzend 
erlaubt die Ubermittlung von fahrzeugspezifischen Informationen uber die 
Luftschnittstelle erne einheifliche, parametrisierbare Funktionalitat im Endgerat sowie 
eine f ahrzeugunabhangige Implementierung im Endgerat. Eine besonders hohe 
Flexibility des Systems wird erreicht, die sich auch sich andernde Ausstattungen der 
Fahrzeuge anpassen kann. 

Bei der Ferndiagnose sind Anderungen oder Verbesserungen im Bezug auf die Diagnose 
selbst, sofern diese nicht Onboard in den Steuereinheiten des Fahrzeugs ablaufen, im 
Server moglich. Dies betrifft vor alien den Ablauf und Umfang (ubertragene Daten) des 
Ferndiagnosevorgangs. 

Besondere Vorteile werden in Verbindung mit der Ferndiagnose erreicht, wenn die 
Kommandos des fahrzeugspezifischen Diagnose-Protokolls tiber die Luftschnittstelle 
vom Server zum Endgerat ubertragen werden. 

Durch die Ressourcenerspamis im Fahrzeugendgerat, insbesondere durch die 
Auslagerung zeitunkritischer Vorgange in den Server des Service-Centers wird eine 
einfache und schnelle Umsetzung auf das Fahrzeugnetzwerk im Endgerat moglich. 

Somit ergibt sich insgesamt eine effiziente und vor allem mit geringem Aufwand 
implementierbare Vorgehensweise zum Einwirken auf eine Fahrzeugfunktionalitat, vor 
allem zur Ferndiagnose, Fernwartung, Fernsteuerung, Software-Download, etc. bei 
Kraftfahrzeugen. 



V 
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Weitere Vorteile ergeben sich aus der nachfolgenden Beschreibung von 
Ausfuhrungsbeispielen bzw. aus den abhangigen Patentanspriichen. 

Zeichnung 

Die Erfindung wird nachstehend anhand der in der Zeichnung dargestellten 
Ausfuhrungsformen anhand der Ferndiagnose eines Kraftfahrzeugs naher erlautert. 
Figur 1 zeigt ein Prinzipbild eines Ferndiagnosesystems. 

In Figur 2 ist als Obersichtsdarstellung die Aufteilung der Diagnosefunktionalitat 
zwischen fahrzeugseitigem und serverseitigem Teil des Systems dargestellt. Insbesondere 
ergeben sich daraus auch Ausgestaltungen des Fahrzeugendgerats bzw. des Servers des 
Service-Centers. 

Figur 3 zeigt ein Ablaufdiagramm, welches den grundsatzlichen Ablauf der Ferndiagnose 
insbesondere im Hinblick auf die tfbertragung zwischen Server und Endgerat sowie im 
Hinblick auf die Funktionen des Endgerats bzw. des Servers in einem bevorzugten 
Ausfiihrungsbeispiel darstellt. 

Figur 4 zeigt die Kommunikation zwischen Server und Endgerat sowie zwischen 
Endgerat und zu diagnostizierendem Steuergerat sowie die in den jeweiligen Einheiten . 
ablaufenden Vorgange im Detail anhand eines bevorzugten Ausfuhrungsbeispiels. 

Beschreibung von Ausfuhrungsbeispielen 

Figur 1 zeigt ein Ubersichtsbild eines Systems fur einen fahrzeugbezogenen 
Telematikdienst, wobei Informationen zwischen einem Fahrzeug (dort Endgerat) und 
einem Server iiber ein Mobilfunknetz bzw. iiber ein Datennetz, wie beispielsweise das 
Internet, ausgetauscht werden. Eine derartige Konfiguration wird in Verbindung mit 
Funktionen zur Fernwirkung, Ferndiagnose, Fernwartung, Software Download, etc. 
eingesetzt. Unter Fernwirkung bzw. Fernabfrage wird dabei im wesentlichen die 
Fernsteuerung von Fahrzeugfunktionen, insbesondere Komfortfunktionen wie das 
Einschalten der Standheizung, etc., sowie das Abfragen von Fahrzeugstati und/oder 
Betriebsparametern verstanden. Dabei initiiert der Nutzer eine Kommunikation mit dem 
Fahrzeug iiber einen zentralen Server oder er kommuniziert direkt mit dem Fahrzeug. 
Ferndiagnose umfasst das Fernauslesen von Diagnosedaten aus dem Fahrzeug, deren 
Analyse und ggf. das Erzeugen einer Empfehlung fur das weitergehende Handeln. 
Analyse der Daten und Generierung der Empfehlung erfolgt dabei durch einen zentralen 
Server, der mit dem Fahrzeug iiber ein Mobilfunknetz, iiber ein drahtgebundenes Netz 
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und/oder liber ein Datennetz wie beispielsweise das Internet mit dem Kraftfahrzeug in 
Verbindung steht. Ferner ist in diesem Zusammenhang als Funktion der sogenannte 
Software-Download bzw. das Remote-Flashing zu nennen, mit deren Hilfe ein neuer 
Programmcode oder Parameter auf per Software konfigurierbare Systeme im Fahrzeug, 
beispielsweise Steuergerate, aufgebracht werden, um die Funktionalitaten oder die 
Leistungsfahigkeit zu erhohen. Auch hier erfolgt die Kommunikation uber ein 
Mobilfunknetz, ein drahtgebundenes Netz und/oder beispielsweise das Internet 
ausgehend von einem zentoden Rechner (Server) bzw. Service-Center. Fernwartung steUt 
im wesentlichen die Uberwachung des Fahrzeugzustandes und den Zugriff auf die 
Wartungsdaten im Fahrzeug von einer zentralen Stelle aus dar, um zu iiberprufen, ob, 
wann und welche MaBnahmen zur Wahrung des Sollzustandes durchgefiihrt werden. Ein 
Beispiel hierfur ist das dynamische Anpassen von Wartungsintervallen. Allgemein 
werden diese Funktionalitaten hier unter dem Begriff des fahrzeugbezogenen 
Telematikdienstes subsumiert. 

Figur 1 zeigt einen fahrzeugseitigen Teil 1 sowie einen serverseitigen Teil 2. Beide Teile 
sind uber eine Kommunikationsschnittstelle 3, insbesondere eine Luftschnittstelle, 
beispielsweise uber ein Mobilfunknetz miteinander verbunden. Der fahrzeugseitige Teil 
besteht aus einem Endgerat 4, beispielsweise einem Telematikendgerat, welches uber 
eine weitere Schnittstelle 5 mit der Fahrzeugelektronik 6 verbunden ist. Der serverseitige 
Teil 2 besteht aus einem Server 7, welcher beispielsweise von einem Service-Center, dem 
Fahrzeughersteller oder einem Zulieferer betrieben wird, und der uber eine Schnittstelle 8 
mit einem Datenspeicher 9 in Verbindung steht, in dem beispielsweise im Rahmen einer 
Datenbank fahrzeugbezogene Daten und/oder Kommandos und/oder Programme abgelegt 
sind. Wie nachf olgend im Detail beschrieben, werden bei dem dargestellten Client- 
Server-System Teilfunktionen partitioniert, d.h. dem Server und den Client bestimmte 
Funktionalitaten eines Telematikdienstes zugeordnet. Dabei wird von einer vollstandigen 
Vernetzung der zu diagnostizierenden bzw. zu steuernden Steuergerate im Fahrzeug mit 
dem Endgerats z.B. durch einen CAN-Bus sowie von der Verfiigbarkeit der Schnittstelle 
3, insbesondere einer MobilfunkschnittsteUe im Kraftfahrzeug, ausgegangen. Die 
bekannten, unterschiedlichen Verfahren fur die Erfassung von Diagnosedaten, 
beispielsweise Uber eine CAN-Bus-Schnittstelle, lassen sich in nichtzeitkritische und 
zeitkritische Anwendungen aufteilen. Zu den nichtzeitkritischen Anwendungen gehort 
beispielsweise die Ablaufsteuerung des Diagnose-Testers, mit Zugriff auf eine 
Datenbank, sowie das Diagnose-Protokoll selbst, beispielsweise das Protokoll KWP2000 
bzw. Varianten davon. Zeitkritische Anwendungen sind das Transport-Protokoll des 
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Fahrzeugnetzes (z.B. CAN-Transport-Protokoll) oder Varianten davon, dessen 
Kommunikationsschicht (z.B. CAN-Konnnunikationsschicht) sowie der Bus (z.B. CAN- 
Bus) selbst. Wesentlich ist, dass bei der Implementierung der Telematikfiinktion im 
Kraftfahrzeug die zeitkritischen Vorgange gegenUber dem unsichereren Mobilfunkkanal 
entkoppelt werden. Daher werden alle oder ein Teil der relevanten Funktionen aus dem 
Fabrzeug ausgelagert, bei denen keine engen zeitlichen Anforderungen bestehen, 
insbesondere Anforderungen beziigliche einer nnnimalen oder maximalen Zeitdauer 
zwischen Kommando und Antwort bei einer Dateniibertragung. Im ExtremfaU bleibt 
daher lediglich der zeitkritische Datentransport auf demFahrzeug-Bus (z.B. CAN-Bus 
oder Ahnliches), welcher durch Funktionen des Transport-Protokolls wie beispielsweise 
die Fragmentierung und Defragmentierung komplexer Nachrichten, realisiert ist, auf der 
Client- bzw. Fahrzeugseite zuriick. Der Funktionsumfang des in der Regel komplexeren 
und fahrzeugspezifischen Dienste-Protokolls (z.B. Diagnoseprotokoll) wird dabei auf 
einen entsprechenden Server (z.B. Diagnoseserver) ausgelagert. Im Anwendungsfall der 
Femdiagnose werden neben der ttbertragung fahrzeugspezifischer Diagnose-Kommandos 
auf der Basis des jeweils- verwendeten Diagnose-Protokolls femer zusatzliche 
Informationen zwischen der Server-Applikation (Ablaufsteuerung fur den 
Gesamtvorgang) und der Client-Applikation (Ablaufsteuerung zur Datenerfassung) 
iibertragen. Diese Ablaufsteuerungen dienen der Aktivierung des Diagnosevorgangs, der 
Konfiguration der Client-Applikation und der spateren Ubennittiung von Ergebnissen der 
serverseitigen Datenanalyse. In dem skizzierten Beispiel, bei dem alle zeitunkritischen 
Vorgange aus dem fahrzeugseitigen Teil in den serverseitigen Teil des Systems 
ausgelagert wurden, ergibt sich die in Figur 2 dargestellte Systemarchitektur. In anderen 
Ausfuhrungen wird nur ein Teil der nichtzeitkritischen Vorgange ausgelagert, wahrend 
ein Teil im fahrzeugseitigen Endgerat verbleibt. So ist beispielsweise vorstellbar, dass 
fahrzeugspezifische Daten und/oder spezielle fahrzeugspezifische Diagnose-Kommandos, 
die aus Sicherheitsgriinden nicht ausgelagert werden, im fahrzeugseitigen Teil des 
Systems verbleiben. 

In Verbindung mit anderen Telematikdiensten wie der Femsteuerung von Komponenten, 
den Softwaredownload, etc. wird auf die geschilderte Art und Weise zeitunkritische 
Anwendungen ausgelagert, wahrend zeitkritische Anwendungen im Fahrzeugendgerat 
verbleiben. 

In Figur 2 ist das Fahrzeugendgerat (Client) 4 sowie der Server 7 dargestellt, welche liber 
eine Luftschnittstelle 3 miteinander verbunden sind. Im bevorzugten Ausfuhrungsbeispiel 
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handelt es sich bei der Luftschnittstelle 3 urn ein herkoramliches, beispielsweise auf dem 
GSM-Standard basierendes Mobilfunknetz. In anderen Anwendungen handelt es sich um 
Mobilfunknetze, die mit anderen Standards arbeiten. Der Server umfasst die folgenden 
Module: ein Mobilfunk-Kommunikations-Protokoll-Modul 7a, ein 
Mobilfunkkommunikation-Modul 7b, ein Ablaufsteuerungs-Modul 7c sowie ein 
fahrzeugspezifisches Diagnose-Protokoll-Modul 7d. Das Fahrzeugendgerat umfasst 
ebenfalls ein Kommunikations-Protokoll-Modul 4a, ein Mcxiul 4b zur Kommunikation 
liber die Mobilfunkschnittstelle, ein Modul 4c zur CAN-Kommunikation sowie ein 
Transport-Protokoll-Modul 4d. Ferner ist eine Ablaufsteuerung 4e im Fahrzeugendgerat 
vorgesehen. Die Module stellen dabei vorzugsweise Softwareprogramme dar. 

Diese Funktionseinheiten haben die folgenden Aufgaben: 

Die Mobilfunkkommunikations-Module 4b, 7b, die sowohl im Endgerat als auch im 
Server vorgesehenen sind, diesen zur stabilen Datenubertragung, zum Verbindungsaufbau 
bzw. -abbau, der Datensicherheit, gegebenenfalls der Verschlusselung, Packetierung, 
etc. Diese Aufgaben werden von ublichen Kommunikationsfuiiktionseinheiten realisiert 
und sind z.B. imRahmen der GSM-Standards verfiigbar. 

Das im Fahrzeugendgerat vorgesehene CAN-Kommunikation-Modul 4c stellt eine 
hardwareunabhangige Softwareschnittstelle zur tJbertragung von Daten uber einen CAN- 
Bus zu angeschlossenen Steuergeraten dar. Dazu gehoren die Initialisierung und 
Steuerung des CAN-Controllers, die tTbertragung und den Empfang von CAN- 
Bausteinen sowie Oberlauf-Fehlerbehandlungen und Weckfunktionen. Ferner umfasst das 
, Modul die Funktionen der OSI-Layer 1 und 2 (Physical Layer, Data Link Layer). Das 
Softwaremodule arbeitet dabei imRahmen der gixltigen CAN-Spezifikation. In anderen 
Ausfiihrungen wird anstelle des CAN-Bus ein anderes Bussysteme eingesetzt 
(standardisiert oder kundenspezifisch), wobei das Softwaremodul dann auf der Basis 
einer entsprechenden Spezifikation realisiert ist. 

Die Ablaufsteuerung 7c im Server zerlegt die Diagnose-Grundfunktionen in einzelne 
Teilprozesse bzw. Diagnose-Services, iibernimmt die Initialisierung des Prozesses, 
steuert und beendet den Diagnosevorgang, verarbeitet die erforderlichen Parameter- und 
gegebenenfalls Protokoll-Mechanismen fur den Diagnosevorgang und steuert den 
Gesamtvorgang zeitlich. Ferner werden hier die ermittelten Diagnosedaten ausgewertet, 
gegebenenfalls eine Generierung einer Empfehlung durchgefiihrt. Ferner Iibernimmt die 
Ablaufsteuerung den Zugriff auf die Diagnose-Datenbank des Servers. Die 
Ablaufsteuerung stellt ein Software-Modul dar, welches fur die spezielle Anwendung 
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konzipiert ist. Ein Beispiel wird nachfolgend anhand der Ferndiagnose in den Figuren 3 
und 4 skizziert. 

In entsprechender Weise ist ein Ablaufsteuerungs-Modul 4e im Fahrzeugendgerat 
vorgesehen. Auch dieses Software-Modul ist fiir die spezielle Anwendung konzipiert. Ein 
Beispiel wird nachfolgend anhand der Ferndiagnose in den Figuren 3 und 4 skizziert. 
Diese Ablaufsteuerung erzeugt eine Server-Anfrage zur Durchfuhrung einer 
Ferndiagnose. Sie konfiguriert die Funktionen im Fahrzeug, beispielsweise durch 
Festlegen einer Tester-Present-Nachricht, Einstellen der Timing-Parameter fiir das 
Transport-Protokoll und gegebenenfalls Einstellen der Parameter fur die CAN- 
Kommunikation. Die Ablaufsteuerung fiihrt ferner die Diagnose-Kommunikation durch 
zyklisches Generierung von Tester-Present-Nachrichten mit den zu diagnostizierenden 
Steuereinheiten durch. Ferner werden von ihr die vom Server ubertragenen Diagnose- 
Kommandos auf das CAN-Transport-Protokoll umgesetzt. Daruber hinaus ubertragt das 
Ablaufdiagramm die Daten an den Server und setzt zu diesem Zweck die im Fahrzeug 
ermittelten Diagnose-Daten auf die Mobilfunkschnittstelle um. Daruber hinaus sind 
MaBnahmen getroffen, mit denen in einem Ausfuhrungsbeispiel die bewerteten 
Ergebnisse der Fehleranalyse, die vom Server ubermittelt werden, angezeigt werden. 
Ferner ubernimmt die Ablaufsteuerung die Beendigung der Diagnose-Kommunikation 
durch Stoppen der Generierung von Tester-Present-Nachrichten. Daruber hinaus wird in 
einem Ausfuhrungsbeispiel das automatische Beenden eines unterbrochenen 
Diagnosevorgangs, z.B. durch Timeout oder Watchdog fiir den Empfang von Server- 
Kommandos, durchgefiihrt. 

Das im Client 4 vorgesehene Transport-Protokoll-Modul 4d fiihrt die tTbertragung von 
komplexen Nachrichten oder Dateneinheiten uber einen CAN-Bus durch, nimmt die 
Entkopplung des Diagnose-Protokolls vom physikalischen Ubertragungsmedium vor und 
stellt die Dienste des OSI-Layers 3 (Network Layer) zur VerfUgung, sowie die 
Verbindung zwischen dem OSI-Layer 2 (Data Link Layer) und 7 (Applikation Layer). Es 
werden als also vom Transport-Protokoll-Modul eine Segmentierung und Erfassung von 
Daten des Data Link Layers vorgenommen, das heiBt die Steuerung des Datenflusses 
einzelner Botschaften inklusive Verwaltung und Zuordnung von physikalischen CAN- 
Botschaften zu logischen Nachrichten oder Dateneinheiten sowie die Fehlererkennung. 
Eine Realisierung stellt das allgemein verbreitete ISO-Transport-Protokoll (ISO 15765-2) 
dar, wobei in anderen Anwendungen auch spezielle Varianten dieses Protokolls 
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eingesetzt werden. Dies gilt auch bei der Verwendung anderer Bussysteme zur 
Kommunikation mit den Fahrzeugsteuergeraten. 

Das dem Server zugeordnete Diagnose-Protokoll-Modul 7d umfasst die Diagnoseschicht, 
welche in einer bevorzugten Anwendung das nach ISO spezifizierte Diagnose-Protokoll 
KWP2000 enthalt, wobei je nach Ausfuhrungsbeispiel auch Varianten davon eingesetzt 
werden. In diesem Diagnose-Protokoll-Modul sind spezielle Diagnose-Dienste definiert, 
die je nach Kraftfahrzeughersteller und/oder Kraftfahrzeugtyp unterschiedlich genutzt 
werden und zum Teil unterschiedliche Zusatzdienste enthalten. Das Diagnose-Protokoll- 
Modul wertet die Diagnose-Anfragen aus. Weitere Aufgaben, die durch das Modul gel6st 
werden, sind die Konvertierung von Diensten in eine funktionale Schnittstelle fur die 
Anwendungsschicht, die direkte Nutzung spezieller Dienste und die 
Ausnahmebehandlung bei Nutzung von unbekannten Diensten. Ein Beispiel fiir die 
Realisierung eines solchen Modul ist aus den nachfolgend beschriebenen 
Vorgehensweisen entnehmbar. 

Die grundsatzliche Vorgehensweise im Rahmen der Ferndiagnose besteht darin, dass 
nach Aktivierung der Ferndiagnose durch eine Bedienperson, z.B. den Nutzer des 
Kraftfahrzeugs, und/oder den Service-Provider und/oder den Fahrzeughersteller und/oder 
eines Monteurs einer Werkstatt nach Abschluss der MaBnahmen zum Verbindungsaufbau 
zwischen Endgerat und Server die Kommandos des fahrzeugspezifischen Diagnose- 
Protokolls iiber die Luftschnittstelle vom Server zum Endgerat ubertragen werden. Die 
fahrzeugspezifischen Diagnose-Protokoll-Kommandos werden dabei vom Diagnose- 
Server nach Identifizierung des zu diagnostizierenden Kraftfahrzeugs aus einer 
Datenbank ausgelesen. Das Endgerat setzt die iibertragenen Diagnose-Kommandos auf 
das Fahrzeugnetzwerk urn. Die erfolgt beispielsweise dadurch, dass die empfangenen 
Kommandos in Kommandos fiir das diagnostizierende Steuergerat umgesetzt werden und 
iiber die Schnittstelle zum Fahrzeugnetzwerk, insbesondere uber einen CAN-Bus, an das 
Steuergerat gesendet werden. Die Antwort dieses Steuergerats wird als Datennachricht 
aus dem Fahrzeugnetzwerk im entsprechenden Format uber die 
Fahrzeugnetzwerkschnittstelle empfangen und wird dann vom Endgerat in 
Antwortnachrichten fur den Server umgesetzt. Diese werden dann an die 
Mobilfunkschnittstelle ubermittelt, die die Nachricht iiber ein vorgesehenes 
tibertragungs-Protokoll (beispielsweise im Rahmen des GSM-Standards) an den Server 
geschickt wird. Zusammenfassend setzt der Client im bevorzugten Ausfuhrungsbeispiel 
also das vom Server iibertragene Diagnose-Protokoll (KWP2000) auf das CAN- 
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Transport-Protokoll urn und umgekehrt. Die Ablaufsteuerung des beschriebenen 
Vorgangs zur Aufrechterhaltung der Diagnose-Kommunikation im Fahrzeug erfolgt im 
Endgerat autark, beispielsweise durch sogenannte Tester-Present-Nachrichten. Diese sind 
in der KWP2000-Spezifikation definiert und dienen der Erfiillung der zeitlichen 
Anforderungen der Fahrzeugnetzwerkes. Dadurch wird eine Entkopplung der 
zeitkritischen Diagnose-Kommunikation im Fahrzeug von den zeitunkritischen 
Diagnoseablaufen im Server erreicht Ergebnis ist somit eine flexible Konfiguration der 
fahrzeugspezifischen Diagnose-Kommunikation im Fahrzeug, die nicht durch mogliche 
Probleme der Luftschnittstelle und der Diagnoseablaufe im Server belastet ist. 

Figur 3 zeigt ein Ablaufdiagramm des Gesamtvorgangs, der in fiinf grundlegende 
Teilschritte gegliedert ist. Die detaillierten Ablaufe innerhalb eines solchen Teilvorgangs 
sind je nach Fahrzeugtyp, dem moglicherweise vorliegenden Fehlerfall und/oder der 
jeweiligen Irnplementierung des Systems im Diagnose-Server variierbar. Im ersten Schritt 
100 erfolgt das Starten der Diagnose mit einer entsprechenden Anfrage an den Server. 
Die Aktivierung erfolgt dabei im bevorzugten Ausfiihrungsbeispiel durch den Fahrer 
bzw. Nutzer des Kraftfahrzeugs der durch Anruf oder Ahnliches beim Service-Center 
eine Aufforderung des Servers an den Client im Fahrzeug erzeugt, eine Diagnose- 
Verbindung aufzubauen. Der Client baut dann die angeforderte Verbindung auf . In 
anderen Ausfuhrungsbeispielen wird die Diagnose-Verbindung durch eine Anfrage vom 
Client aus aufgebaut. Der Aufbau der eigentlichen Diagnose-Verbindung erfolgt hier 
durch den Server oder den Client. Im nachsten Schritt 200 erfolgt die Konfiguration der 
Ferndiagnose-Funktionalitat im Fahrzeug durch den Server. Dabei wird die 
Ablaufansteuerung, die Transportschicht und gegebenenfalls die CAN-Kommunikation 
an das spezifische Fahrzeug angepasst Dies erfolgt durch Kommandos bzw. Daten vom 
Server, die dieser aus einer Datenbank flir das spezielle Fahrzeug bzw. Fahrzeugtyp / 
und/oder Austattungsvariante ausliest. Bei der Aktivierung erhalt der Server 
beispielsweise mittels eines Identifikationscodes Informationen iiber das zu 
diagnostizierende Fahrzeug. Anhand dieser Information liest er fahrzeugspezifische 
Parameter aus der Datenbank aus, die er dann an den Client zur Konfiguration der 
Ferndiagnose-Funktionalitat iibermittelt. 

Nach den Teilschritten Aktivierung (100) und Initialisierung (200) wird der Teilschritt 
Ausfiihrung des Diagnosevorgangs (301 bis 303) an einem Beispiel eines Steuergerats 
gezeigt. Zunachst wird im Schritt 301 durch den Server imzu diagnostizierenden 
Steuergerat, sofern dies notwendig ist, der Diagnosemode angestoBen, so dass das 
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Steuergerat zum Ausfuhren der Diagnose-Funktion in der Lage ist. Fenier erfolgt die 
Identifikation des Steuergerat, z.B. dessen Softwarestand zur Anpassung der Diagnose- 
Kommandos an den speziellen Steuergeratetyp. Auch dies ist optional und wird dann 
eingesetzt, wenn dies z.B. aufgrund der Vielzahl von Softstanden sich als erforderlich 
erweist. Danach werden die ausgewahlten Diagnose-Kommandos vom Server an den 
Client im Fahrzeug iibertragen. Beispiele fur solche Diagnose-Kommandos sind das 
Auslesen wenigstens eines Fehlerspeichers des betroffenen Steuergerats, das Auslesen 
von gespeicherten Umgebungs-Parameter eines aufgetretenen Fehlers und/oder das 
Abfragen von zusatzlichen Ist-Werten aus dem entsprechenden Steuergerat. 

Im Schritt 302 setzt der Client das oder die ubermittelten Diagnose-Kommandos auf das 
Fahrzeugnetzwerk urn. Im darauf folgenden Schritt 303 wird die Antwort des 
Steuergerats auf das oder die gesendeten Kommandos, welche beispielsweise innerhalb 
einer bestimmten Zeitperiode auftreten muss, empfangen, vom Client iiber auf die 
tibertragungsschnittstelle zum Server umgesetzt und an diesen zurizckgesendet. Die 
Schritte 301 bis 303 werden dann fur jedes zu diagnostizierende Steuergerat oder, wenn 
die Diagnosekommandos einzeln nacheinander oder in Gruppen nacheinander versendet 
werden, fiir jedes einzelne Diagnose-Kommando oder Diagnose-Kommando-Gruppe 
wiederholt. Ist die Diagnose fiir ein Steuergerat beendet, wird als Diagnose-Kommando 
ein Ende-Kommando gesendet, welches ggf. den Diagnose-Mode im Steuergerat 
deaktiviert und dieses wieder in den normalen Betriebsmode zuriickversetzt. 

Der vierte Teilschritt betrifft die Auswertung der erhaltenen Daten im Server (Schritt 
400). Der Server wertet der nach MaBgabe eines ggf. spezifischen Algorithmus die 
gesammelten Fehlerinformationen aus, ermittelt ein Diagnose-Ergebnis und/oder 
Empfehlungen fiir das weitere Vorgehen. Im darauf folgenden Schritt 500 werden dann 
die vom Server ermittelten Ergebnisse an das Endgerat iibertragen und von diesem im 
Fahrzeug angezeigt. Dieser fiinfte Teilschritt stelle somit die Ergebnisausgabe dar. Im 
diesem Schritt ist auch in einem Ausfiihrungsbeispiel die tJbermittlung und Anzeige einer 
Empfehlung fiir das weitere Vorgehen im Fehlerfall vorgesehen, z.B. „Werkstatt 
aufsuchen", etc. 

Figur 4 zeigt ein beispielhaftes Kommunikationsszenario zwischen einem Ferndiagnose- 
Server, einem Telematikendgeriit und einem Steuergerat. Das Kommunikationsszenario 
stallt eine Realisierung des dritten Teilschritt in Figur 3 im Detail dar. Basis der 
Kommunikation ist das nach ISO 14230-3 spezifizierte Diagnose-Protokoll KWP2000. In 
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anderen Ausfuhrungsbeispielen werden herstellerspezifische Varianten dieses Diagnose- 
Protokolls Oder auch andere Diagnose-Protokolle entsprechend eingesetzt. Je nach 
Ausfuhrungsbeispiel variiert die Abfolge der Schritte und der Umfang der Schritte in den 
einzelnen Anwendungen. Figur 4 zeigt eine bevorzugte Realisierung der Kommunikation 
zwischen einem Femdiagnose-Server I, einem imFahreeug angeordneten 
Telematikendgerat II und einem zu diagnostizierenden Steuergerat DI. Die 
Kommunikation basiert dabei auf dem Diagnose-Protokoll KWP2000, welches in der 
ISO 14230-3 spezifiziert ist. Die Fehlerermittlung und das Setzen der Fehlerspeicher 
erfolgt dabei in den meisten Falle durch bekannte Diagnosemethoden im zu 
diagnostizierenden Steuergerat durch dort vorhandene oder dort eingelesene Software. 

In Figur 4 sind die einzelnen einer Kommunikation zwischen den drei beteiligten 
Einheiten dargesteUt, wobei von oben nach unten eine zeitliche Reihenfolge ausgedruckt 
sein soil. In den Einheiten sind Softwareprogramme vorhanden, die die zu ubermittlenden 
Nachrichten erzeugen, auswerten, etc. 

Nach Abschluss der Teilvorgange 1 und 2 (siehe Figur 3, Schritte 100 und 200) wird in 
einem ersten Schritt SI der Diagnose-Mode im zu diagnostizierenden Steuergerat 
aktiviert. Dazu sendet der Server ein entsprechendes Diagnose-Kommando (Start- 
Diagnostic-Session-Request). Dieses wird vom Endgerat empfangen und uber die 
Schnittstelle zum diagnostizierenden Steuergerat weitergeleitet (Schritt S2) bzw. zuerst in 
ein fiir das Fahrzeugnetz geeignetes Format umgesetzt (z.B. mittels einer Tabelle) und 
dann auf das Fahrzeugnetz gegeben. Das zu diagnostizierende Steuergerat antwortet mit 
einer entsprechenden Antwort (Start-Diagnostic-Session-Response), die angibt, ob der 
Diagnose-Mode eingeleitet ist oder nicht. Diese Information sendet das zu 
diagnostizierende Steuergerat im Schritt S3 zum Endgerat, welches wiederum im Schritt 
S4 (ggf. nach Umsetzung auf das vorgesehene Format) die Information zum Server 
ubertragt. 

Daraufhin wird zur Ablaufsteuerung und zur Erfullung der Zeitanforderung im 
Fahrzeugnetz vom Endgerat H zum Steuergerat HI im Schritt S5 eine Kommando 
geschickt (Tester-Present-Request), welches im Schritt S6 von Steuergerat mit einer 
entsprechenden Antwort (Tester-Present-Response) beantwortet wird. Diese 
Kommunikation wird imfolgenden wahrend des Diagnosevorgangs dann ausgefuhrt, 
wenn vom Server kein anderes Diagnose-Kommando weiterzuleiten ist bzw. vom 
Steuergerat keine Antwort an den Server zu leiten ist Daher konnen die Schritte S5 und 
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S6 auch mehxfach wiederholt werden, solange bis das erwartete Kommando voxn Server 
empfangen wird. Tritt ernes der genannten Ereignisse nicht auf, wird die Kommunikation 
zwischen Endgerat und Steuergerat abgebrochen. 

Nach Empfang der Antwort im Schritt S4 sendet der Server im Schritt S7 ein Kommando 
(Read ECU-Identification-Request), welches die Identification des zu diagnostierenden 
Steuergerats anfragt. Dieses Kommando wird vom Endgerat empfangen und ggf. 
umgesetzt und dann im Schritt S8 zum Steuergerat ubermittelt. Das Steuergerat liest aus 
seinem Speicher daraufhin wenigstens einen Identifikationsparameter aus und sendet 
diesen zum Endgerat (Read ECU-Identification-Response, Schritt S9). Diese Information 
wird dann ggf. nach Umsetzung vom Endgerat II im Schritt S 10 an den Server 
ubertragen. Anhand des Identifikationsparameters erkennt der Server das Steuergerat, 
gegebenenfalls dessen Software-Stand sowie gegebenenfalls das Fahrzeug und wahlt aus 
der Datenbank entsprechende Parameter aus. In der Zwischenzeit lauft, wie anhand der 
Schritte Sll und S12 dargestellt, zwischen Endgerat und zu diagnostizierenden 
Steuergerat die oben beschriebene Tester-Present-Kommunikation ab, die sicherstellt, 
dass die Kommunikation zwischen Endgerat und Steuergerat aufrechterhalten bleibt, das 
Steuergerat im Diagnosemode verbleibt und keine Verletzung der Randbedingungen fur 
die Kommunikation im Fahrzeugsnetz, die zum Abbruch fuhrt, erfolgt. 

In den nachsten Schritten werden die Fehlerspeicher des zu diagnostizierenden 
Steuergerats ausgelesen. Dazu ubermittelt der Server nach Empfang der Nachricht im 
Schritt S10 und Auslesen der steuergeratspezifischen Parameter zum Endgerat im Schritt 
S13 eine entsprechende Anfrage (Read DTC-Request). In dieser Anfrage sind die 
steuergeratspezifischen Parameter enthalten, in denen z.B. angegeben ist, welche 
Fehlerspeicher auszulesen sind. Diese Anfrage wird im Schritt S14 von Endger&t ggf. 
nach Umsetzung zum Steuergerat ubertragen. Das Steuergerat fuhrt die empfangenen 
Kommandos aus und sendet die Fehlerspeicherinhalte als Botschaft Read DTC-Response 
im Schritt S15 zum Endgerat. Die Botschaft Read DTC-Response enthalt demnach die 
relevanten Fehlerspeicherinhalte. Die Antwort wird vom Endgerat ggf. nach Umsetzung 
im Schritt S16 zum Server ubertragen. Daraufhin wird in den Schritten S17 und S 18 die 
oben erwahnte Tester-Present-Kommunikation zwischen Endgerat und Steuergerat bis 
zum erneuten Empfang einer Botschaft vom Server durchgefiihrt. 

Im darauf folgenden, optionalen Teilschritt werden die zu den Fehlereintnigen gehorige 
Umgebungsparameter ausgelesen. Zu diesem Zweck sendet der Server nach Empfang der 
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Botschaft im Schritt S16 und nach Auswertung der Fehlereintrage im Schritt S 19 an das 
Endgerat eine entsprechende Anfrage (Read-Freeze Frame-Request), die dieses ggf. nach 
Umsetzung im Schritt S20 an das Steuergerat weitergibt. Je nach Ausfuhrung liest das 
Steuergerat dann die gewiinschten Parameter zu den gespeicherten Fehlern aus oder der 
Server spezifiziert anhand der Inhalte der Fehlerspeicher den Inhalt seiner Botschaft, so 
dass mit dieser Botschaft nur bestimmte Umgebungsparameter angefordert werden. Das 
Steuergerat jedenfalls antwortet mit einer entsprechenden Antwort (Read-Freeze Frame- 
Response), in welchem die auf die eine oder andere Weise angeforderten Parameter 
enthalten sind. Im Schritt S21 wird die Antwort an das Endgerat gesendet, welches die 
Antwort wiederum ggf. nach Umsetzung im Schritt S22 zum Server tibertrag. In den 
Schritten S23 und S24 erfolgt erneut die Tester-Present-Kommunikation. 

Im darauf folgenden Teilschritt, nach dem Fehlerspeicher und zugehorige 
Umgebungsparameter ausgelesen und ubertragen sind, wird der Diagnosemode im 
Steuergerat deaktiviert Hierzu schickt der Server eine Aufforderung zum Beenden die 
Diagnosevorgangs (Stop-Diagnostic-Session-Request) an das Endgerat Dieses gibt die 
Aufforderung zum Beenden an das Steuergerat weiter (Schritt S26), welches mit einem 
entsprechenden Antwortsignal (Stop-Diagnostic-Session-Response) im Schritt 27, mit 
welcher das Steuergerat die Beendigung des Diagnose-Modus mitteilt, antwortet. Diese 
Information wird vom Endgerat im Schritt S28 zum Server ubertragen. Daraufhin (Schritt 
S29) werden die oben dargestellten Teilvorgange 4 und 5 beziiglich Auswertung und 
Anzeige der Diagnose-Ergebnisse und ggf. -Empfehlungen weitergefiihrt. 

Das dargestellte Kommunikationsszenario ist ein Beispiel. In anderen Ausfuhrungen 
fehlen die Schritte zum Aktivieren und Deaktivieren des Diagnose-Modes im Steuergerat 
und/oder zur Identifikation des Steuergerats und/oder zum Auslesen der zugehorigen 
Umgebungsparameter. 



Die konkrete technische Realisierung der dargestellten Kommunikation findet durch 
entsprechende Software-Programme in Server, Endgerat und Steuergerat statt, die jedes 
fur sich ebenfalls Teil der vorliegenden Erfindung sind. 
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Patentanspruche 

1 . Verfahren fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server) und einem Endgerat, welches vorzugsweise im Kraftfahrzeug angeordnet ist, 
zwischen denen eine Kommunikationsverbindung besteht, dadurch gekennzeichnet, 
dass der Telematikdienst in Teilfunktionalitaten aufgeteilt ist, welche wiederum auf 
Server und Endgerat aufgeteilt sind, wobei im Server zeitunkritische 
Funktionalitaten, im Endgerat zeitkritische Funktionalitaten ablaufen.. 

2. Verfahren fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server), welcher mit einem Endgerat eine Kommunikationsverbindung aufbaut, 
dadurch gekennzeichnet, dass der Telematikdienst in Teilfunktionalitaten aufgeteilt 
ist, wobei im Server zeitunkritische Funktionalitaten ablaufen. 

3. Verfahren fur einen fahrzeugbezogenen Telematikdienst, mit einem vorzugsweise im 
Kraftfahrzeug angeordneten Endgerat, welches mit einem Zentralrechner (Server) 
eine Kommunikationsverbindung aufbaut, dadurch gekennzeichnet, dass der 
Telematikdienst in Teilfunktionalitaten aufgeteilt ist, wobei im Endgerat zeitkritische 
Funktionalitaten ablaufen. 

4. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, dass 
die zeitkritischen Teilfunktionalitaten autark im Endgerat ablaufen, die 
zeitunkritischen Teilfunktionalitaten vom Server mittels Kommunikatioon mit dem 
Endgerat durchgefiihit werden. 
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5. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, dass 
im Endgerat die zeitkritische Kommunikation mit einem zu diagnostizierenden 
Steuergerat und/oder einer zu diagnostizierenden Komponenten implementiert ist. 

6. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, dass 
der Telematikdienst eine Ferndiagnose eines Kraftfahrzeugs ist und dass das 
Diagnose-Protokoll im Server implementiert ist. 

7. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, dass 
Kommandos des fahrzeugspezifischen Diagnose-Protokolls iiber eine 
Luftschnittstelle vom Server zum Endgerat ubertragen wird. 

8. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, dass 
das Endgerat die iibertragenen Diagnose-Kommandos auf ein Fahrzeugnetzwerk 
umsetzt und die erzeugten Antwortnachrichten an die Mobilfunkschnittstelle 
ubermittelt. 

9. Verfahren nach einem der vorhergehenden Anspriiche, dadurch gekennzeichnet, dass 
, als Diagnose-Protokoll KWP2000 oder eine Variante davon eingesetzt wird. 

10. Vorrichtung fUr einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server) und einem Endgerat, welches vorzugsweise im Kraftfahrzeug angeordnet ist, 
zwischen denen eine Kommunikationsverbindung besteht, dadurch gekennzeichnet, 
dass der Telematikdienst in TeUfunktionalitaten aufgeteilt ist, welche wiederum auf 
Server und Endgerat aufgeteilt sind. 

11. Vorrichtung fur einen fahrzeugbezogenen Telematikdienst, mit einem Zentralrechner 
(Server), welcher mit einem Endgerat eine Kommunikationsverbindung aufbaut, 
dadurch gekennzeichnet, dass der Telematikdienst in TeilfunktionaUtaten aufgeteilt 
ist, wobei im Server zeitunkritische Funktionalitaten ablaufen. 

12. Vorrichtung fur einen fahrzeugbezogenen Telematikdienst, mit einem vorzugsweise 
im Kraftfahrzeug angeordneten Endgerat, welches mit einem Zentralrechner (Server) 
eine Kommunikationsverbindung aufbaut, dadurch gekennzeichnet, dass der 
Telematikdienst in Teilfunktionalitaten aufgeteilt ist, wobei im Endgerat zeitkritische 
Funktionalitaten ablaufen. 
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13. Vomchtung nach Anspruch 10 oder 11, wobei der Server iiber eine Luftschnittstelle 
mit dem Endgerat kommuniziert, dadurch gekennzeichnet, dass der Telematikdienst 
eine Ferndiagnose eines Kraftfahrzeugs ist, wobei das Diagnose-Protokoll als 
zeitunkritische Teilfunktionalitat im Server implementiert ist. 

14. Voirichtung nach Anspruch 10 oder 12, wobei das Endgerat uber eine 
Luftschnittstelle mit dem Server kommuniziert und welches eine weitere Schnittstelle 
umfasst, mit dem es mit einer zu diagnostizierenden Einheit verbunden ist, dadurch 
gekennzeichnet, dass das Endgerat als zeitkritische Teilfunktionalitat eine 
Ablaufsteuerung umfasst, die autark gegenuber der zentralen Recheneinheit ist und 
die die Diagnose-Kommunikation im Fahrzeug aufrecht erhalt. 

15. Computerprogramm mit Programmcode-Mitteln, urn alle Schritte von jedem 
beliebigen der Anspriiche 1 bis 9 durchzufuhren, wenn das Programm auf einem 
Computer ausgefuhrt wird. 

16. Computerprogrammprodukt mit Programmcodemitteln, die auf einem 

. computerlesbaren Datentrager gespeichert sind, um das Verfahren nach jedem 
beliebigen der Anspriiche 1 bis 9 durchzufuhren, wenn das Programmprodukt auf 
einem Computer ausgefuhrt wird. 
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Verfahren und Vorrichtung fur einen fahrzeugbezogenen Telematikdienst 
Zusammenfassung 

Es werden ein Verfahren und Vorrichtung fiir einen fahrzeugbezogenen Telematikdienst 
vorgeschlagen, bei welchem der Telematikdienst in Teilfunktionalitaten untergliedert ist 
und diese Teilfunktionalitaten auf Server und Endgerat aufgeteilt sind. 



(Figur 2) 
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